⚙️ FEATURE-#21: Replace tool-card emoji with codicons, go-to-file, and auto-approved diffs - #22

This PR cleanly replaces emoji tool-card icons with VS Code's native codicon font and adds a go-to-file action. The implementation is well-structured, tests are updated, and the CSP is correctly extended. A few items worth addressing before merge:

[Suggestion]

Problem — openFile resolves relative paths against currentWorkspaceFolder() with no sanitisation. A path like ../../.ssh/id_rsa is resolved and opened in the editor without any guard. Even though the webview is sandboxed, path traversal outside the workspace is undesirable and could expose sensitive files.

Failure scenario — A chat message triggers chat/autoApproved with a crafted tool whose args.path is ../../../home/user/.ssh/id_rsa; the user clicks the go-to-file button and VS Code opens the file.

Fix — After resolving the URI, verify it stays within the workspace root before calling showTextDocument:

private openFile(filePath: string): void {
  const root = currentWorkspaceFolder();
  const resolved = path.isAbsolute(filePath)
    ? filePath
    : path.join(root, filePath);
  const normalized = path.normalize(resolved);
  if (!normalized.startsWith(path.normalize(root) + path.sep)) {
    vscode.window.showErrorMessage(`Path outside workspace: ${filePath}`);
    return;
  }
  const uri = vscode.Uri.file(normalized);
  vscode.window.showTextDocument(uri).then(undefined, () => {
    vscode.window.showErrorMessage(`Couldn't open ${filePath}`);
  });
}

[Suggestion]

Problem — The .tool-open-file:hover CSS rule is not scoped under .tool-card-header, unlike the sibling rule .tool-card-header .tool-open-file. This inconsistency means the hover style leaks globally: any future .tool-open-file element outside a .tool-card-header will pick up the colour change unexpectedly.

Failure scenario — A future refactor adds a .tool-open-file button in a different context (e.g. a result panel); its hover colour is silently affected by this rule.

Fix — Scope the hover rule to match its companion:

.tool-card-header .tool-open-file:hover {
  color: var(--vscode-foreground);
}

[Comment]

Problem — The openFile handler receives message.path directly from the webview and passes it to path.join / path.isAbsolute without any type narrowing beyond what TypeScript's union type provides at compile time. At runtime, a tampered message (e.g. via a browser DevTools injection into the webview) could supply a non-string value.

Failure scenario — message.path is null; path.isAbsolute(null) coerces to path.isAbsolute("null") returning false, then path.join(root, "null") opens a file named null in the workspace.

Fix — Add a runtime guard at the handler level, consistent with how other handlers coerce values (e.g. String(message.value ?? "")):

case "openFile":
  if (typeof message.path === "string" && message.path.length > 0) {
    this.openFile(message.path);
  }
  break;